1. Field of the Invention
The present invention relates to a method of communicating between a host and a peripheral device. More particularly, this invention relates to a method of communicating between the host and the peripheral device via a USB connection.
2. Description of the Related Art
FIG. 1 is a schematic diagram illustrating a host computer system 200 connected to a USB mass storage device 100 via a USB connection 120. FIG. 2 is a high level USB system block diagram illustrating various hardware and software components for controlling a USB mass storage device 100. Referring to FIGS. 1 and 2, a USB mass storage driver 125 resides is a client USB driver that executes on the host computer system 200. The USB mass storage driver 125 provides the interface between the Operating System (OS) Storage driver stack 124 and the USB mass storage device 100. The USB Driver 132 provides the system software that supports USB on a particular OS. The Host Controller Driver (HCD) 134 provides the software layer between the host controller hardware 142 and the USB driver 132.
The USB hardware 140 includes the host controller 142, the USB 120, and the USB mass storage device 100. The host controller 142 is managed by the HCD software layer 134. The host controller hardware 142 executes a scheduled list of transactions generated by the HCD 134 and reports the status of the transactions on the USB 120 to the HCD 134. The USB mass storage device 100 is a hardware device built according to the USB Mass Storage Class (MSC) specifications. Interactions between the USB mass storage device 100 and the host computer system 200 flow through the software and hardware layers described previously.
Conventional USB MSC drivers synchronously submit the three phases (Command, Data, and Status) of a bulk-only transport protocol. This synchronous transmission scheme results in dead time between each of the three phases because each phase is separately subject to an interrupt latency based on a current interrupt threshold. FIG. 3 is a schematic block diagram illustrating the conventional synchronous method of communication. FIG. 4 is a software trace showing the timing of signals according to the conventional synchronous method of FIG. 3.
Referring to FIGS. 2, 3, and 4, according to the synchronous communication method, the communication begins with a start request in the USB mass storage driver 125 executing on the host computer system 200. In response to the start request, a command transport is submitted to the USB driver stack 130 and a setup command transaction for the host controller 142 is initiated. A command USB bulk transaction is then processed in the host controller 142. When the command transaction is completed in the USB driver stack 130, a command transport callback is received in the USB mass storage driver 125. During the processing of the command bulk USB transaction in the host controller 142, the USB Device 100 extracts the command block and executes the command.
The command phase takes place during a first frame time on the USB 120. The length of each frame corresponds with an interrupt threshold of the USB. Following the processing of the command, the USB sits idle until the end of the first frame time (i.e., completion of the first interrupt threshold period). Only after the first frame has completed can the data phase begin.
During the data phase, a data transport is submitted from the USB Mass Storage Class Driver 125 to the USB driver stack 130. A data transaction for the host controller 142 is then set up by the USB driver stack 130. The host controller 142 then processes the data USB bulk transaction. During the data USB bulk transaction, data is transmitted between the USB device 100 and the host 200 over the USB 120, as specified in the command block. When the data transaction is complete, a data transport callback is received in the USB Mass storage driver 125.
The data phase takes place during a second frame time. The next phase (status) cannot take place until the second frame has ended. The USB therefore sits idle from the completion of the data transfer and the end of the second frame.
Following the second frame, the status phase begins with the submission of the status transport from the USB mass storage driver 125 to the USB Driver stack 130. The USB driver stack 130 then sets up the status transaction for the host controller 142. The host controller 142 then processes the status USB bulk transaction. During the status USB bulk transaction, the USB device 100 returns status information regarding the execution of the command block. When the status USB bulk transaction is complete, a status transport callback is received in the USB Mass Storage driver 125 and the request is complete.
The status phase, however, takes place during a third frame time and the next transaction cannot begin until the completion of the third frame. Between the time when the status information has been returned and the completion of the third frame, the USB again sits idle.
FIG. 5 is a schematic block diagram further illustrating the problems resulting from the synchronous communications method. Referring to FIG. 5, each frame arrow 10 represents a single interrupt threshold for a USB frame. In this example, each interrupt threshold has a length of 1 ms. Accordingly, a Command phase 20, a Data phase 30, and a Status phase 40 each take one USB frame (or 1 ms) to complete. In this example, therefore, the synchronous method takes approximately 3 ms to complete all three phases of the bulk-only transport protocol, as indicated by transaction arrows 15.